ETSITS129 011 V9.0.0 



(2010-01) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+) 
Universal Mobile Telecommunications System (UMTS) 

LTE 
Signalling Interworking for supplementary services 
(3GPP TS 29.011 version 9.0.0 Release 9) 



JtSiP 





3GPP TS 29.01 1 version 9.0.0 Release 9 1 ETSI TS 1 29 01 1 V9.0.0 (201 0-01 ) 



Reference 



RTS/TSGC-04290 11 v900 
Keywords 



GSM, LTE, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2010. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 29.01 1 version 9.0.0 Release 9 2 ETSI TS 1 29 01 1 V9.0.0 (201 0-01 ) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 29.01 1 version 9.0.0 Release 9 3 ETSI TS 1 29 01 1 V9.0.0 (201 0-01 ) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

1.1 Normative references 6 

1.2 Definitions and abbreviations 7 

2 Introduction 8 

2.1 MSC/VLR procedures for handling supplementary service signalling received over the A-interface 8 

2.2 MSC/VLR procedures for handling supplementary service signalling received over the D-interface 8 

3 SS version negotiation 8 

3.1 Call related supplementary services interworking 8 

3.2 Call independent supplementary services interworking 8 

4 Mapping between TC transaction sublayer messages and layer 3 radio path messages 9 

4.1 D-interface to A-interface mapping 9 

4.2 A-interface to D-interface mapping 9 

4.3 Procedures 10 

5 Call related supplementary services management 10 

5.1 SS management in connection establishment phase 10 

5.1.1 Line Identification services 10 

5.1.1.1 Calling Line Identification Presentation (CLIP) 11 

5.1.1.2 Calling Line Identification Restriction (CLIR) 11 

5.1.1.3 Connected Line Identification Presentation (COLP) 11 

5.1.1.4 Connected Line Identification Restriction (COLR) 12 

5.1.2 Call Forwarding services 12 

5.1.2.1 Notification to served mobile subscriber 12 

5.1.3 Call Waiting service (CW) 12 

5.1.3.1 Offering a waiting call 12 

5.1.3.2 Notification of waiting call to calling subscriber 13 

5.1.4 Closed User Group service (CUG) 13 

5.1.4.1 Explicit invocation of a CUG call 13 

5.1.4.2 Notification of CUG invocation to served MS 14 

5.1.4.3 Notification of rejection of CUG invocation to served MS 14 

5.1.4.4 Notification of CUG invocation to terminating MS 15 

5.1.5 Advice of Charge services 16 

5.1.5.1 Notification of Charging information to served MS, mobile originated call 16 

5.1.5.2 Notification of Charging information to served MS, mobile terminated call 16 

5.1.6 Call Barring services 17 

5.1.6.1 Barring of outgoing calls 17 

5.1.6.2 Barring of incoming calls 17 

5.1.7 CCBS call outcome 18 

5.2 SS Management in stable connection state 18 

5.2.1 Call Forwarding services 18 

5.2.1.1 Notification of invocation of CFB to served mobile subscriber 18 

5.2.2 Call Hold service (HOLD) 19 

5.2.3 Multi Party service (MPTY) 20 

5.2.4 Advice of Charge services 20 

5.2.5 Explicit Call Transfer service (ECT) 21 

5.3 SS Management in disconnecting phase 21 

5.3.1 Call Forwarding services 22 

5.3.2 CCBS Request Activation 22 

5.3.3 Call Deflection service 23 

5.3.3.1 Call Deflection Operation Request 23 

5.3.3.2 Call Deflection Operation Response 23 



£75/ 



3GPP TS 29.01 1 version 9.0.0 Release 9 4 ETSI TS 1 29 01 1 V9.0.0 (201 0-01 ) 

6 Call independent supplementary services management 24 

6.1 MS initiated SS Management 24 

6.1.1 Connection establishment phase 24 

6.1.2 Connection established 24 

6.1.3 Connection release 25 

6.2 Network initiated SS Management 26 

6.2.1 Connection establishment phase 26 

6.2.2 Connection established 26 

6.2.3 Connection release 27 

6.2.4 ForwardCheckSSIndication 27 

6.2.5 CCBS Recall 27 

6.2.6 CCBS Monitoring 28 

6.3 Mapping of Operation Codes, Error Codes, Parameter Tags and Parameter Contents 28 

6.3.1 Operation codes 28 

6.3.2 Error codes 29 

6.3.3 Parameter tags and parameter values 29 

Annex A (informative): Change history 30 

History 31 



£75/ 



3GPP TS 29.01 1 version 9.0.0 Release 9 5 ETSI TS 1 29 01 1 V9.0.0 (201 0-01 ) 



Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



The scope of this Technical Specification is to provide a detailed specification for interworking between the A interface 
protocol and the Mobile Application Part for handling of supplementary services. The MAP interfaces of interest are the 
B-, C-, D- and E-interfaces. 

The A-, C-, D- and E-interfaces are physical interfaces while the B-interface is an internal interface defined for 
modelling purposes. Information relating to the modelling interface is not normative in this specification. 

Supplementary service signalling may be passed by the MSC/VLR between the A- and E-interfaces after inter-MSC 
handover. This procedure is transparent as far as supplementary services are concerned therefore interworking 
concerning this process is not described in this specification. 

Clause 2 describes general procedures for interworking between the A- and D- physical interfaces. 

Clause 3 describes the general procedures for the SS version negotiation. 

Clause 4 describes the mapping of layer 3 radio path messages with Transaction Capabilities (TC) transaction sublayer 
messages for interworking between the A- and D- physical interfaces. 

Clause 5 describes specific interworking procedures for all interfaces relating to call related SS activity. 

Clause 6 describes specific interworking procedures for all interfaces relating to call independent SS activity. Clause 6 
also covers the interworking between the MAP User (see 3GPP TS 29.002) and the SS handling functions of the 
network entities (see 3GPP TS 24.010 and 3GPP TS 24.080). 

Reference is made to the following Technical Specifications: 

- 3GPP TS 22.004 and 3GPP TS 22.08x and 3GPP TS 22.09x-series, 
for definition of supplementary services; 

- 3GPP TS 23.01 1, 3GPP TS 23.08x and 3GPP TS 23.09x-series, 
for technical realisation of supplementary services; 

- 3GPP TS 24.010, 3GPP TS 24.080, 3GPP TS 24.08x and 3GPP TS 24.09x-series, 
for radio path signalling procedures for supplementary services; 

- 3GPP TS 29.002 (MAP). 

1.1 Normative references 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 
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For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in 
the same Release as the present document. 



'General on supplementary services". 

'Description of Charge Advice Information (CAI)". 

'Call Forwarding (CF) supplementary services - Stage 1". 

'Advice of Charge (AoC) supplementary services - Stage 1". 

'Completion of Calls to Busy Subscriber - Stage 1". 

'Technical realization of supplementary services". 

'Advice of Charge (AoC) supplementary services - Stage 2". 

'Completion of Calls to Busy Subscriber - Stage 2". 

'Mobile radio interface layer 3 specification". 

'Mobile radio interface layer 3 Supplementary services specification General 

'Call Deflection supplementary service - Stage 3". 

'Mobile radio interface layer 3 supplementary services specification Formats 

'Line identification supplementary services - Stage 3". 

'Call Forwarding (CF) supplementary services - Stage 3". 

'Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 3". 

'Multi Party (MPTY) supplementary services - Stage 3". 

'Closed User Group (CUG) supplementary services - Stage 3". 

'Advice of Charge (AoC) supplementary services - Stage 3". 

'Call Barring (CB) supplementary services - Stage 3". 

'Unstructured supplementary services operation - Stage 3". 

'Explicit Call Transfer (ECT) supplementary services - Stage 3". 

'Completion of Calls to Busy Subscriber - Stage 3". 

'Mobile Application Part (MAP) specification". 

'Information element mapping between Mobile Station - Base Station System 
and BSS - Mobile-services Switching Centre (MS - BSS - MSC) Signalling procedures and the 
Mobile Application Part (MAP)". 



[1] 


3GPPTR 21.905: 


[2] 


3GPP TS 22.004: ' 


[3] 


3GPP TS 22.024: ' 


[4] 


3GPP TS 22.082: ' 


[5] 


3GPP TS 22.086: ' 


[6] 


3GPPTS 22.093:' 


[7] 


3GPPTS 23.011:' 


[8] 


3GPPTS 23.086:' 


[9] 


3GPPTS 23.093:' 


[10] 


3GPP TS 24.008: ' 


[11] 


3GPP TS 24.010: ' 




aspects". 


[12] 


3GPP TS 24.072: ' 


[13] 


3GPP TS 24.080: ' 




and coding". 


[14] 


3GPPTS 24.081:' 


[15] 


3GPP TS 24.082: ' 


[16] 


3GPP TS 24.083: ' 


[17] 


3GPP TS 24.084: ' 


[18] 


3GPPTS 24.085:' 


[19] 


3GPP TS 24.086: ' 


[20] 


3GPP TS 24.088: ' 


[21] 


3GPP TS 24.090: ' 


[22] 


3GPPTS 24.091: ' 


[23] 


3GPPTS 24.093:' 


[24] 


3GPP TS 29.002: ' 


[25] 


3GPP TS 29.010: ' 



1.2 



Definitions and abbreviations 



Abbreviations used in this specification are listed in 3GPP TR 21.905. 



£75/ 



3GPP TS 29.011 version 9.0.0 Release 9 8 ETSI TS 129 Oil V9.0.0 (2010-01) 

2 Introduction 

This clause describes general procedure at the MSC/VLR for SS interworking between the A- and D-interfaces. 

2.1 MSC/VLR procedures for handling supplementary service 
signalling received over the A-interface 

Upon receipt of supplementary service signalling on the A-interface, the MSC/VLR shall: 

perform any internal SS checks or procedures appropriate to the signal (see clauses 4 and 5); 

if necessary request access to the HLR over the D-interface using the procedures defined in this specification and 
MAP, 3GPP TS 29.002; 

use the version indicator received from the MS to set up the right AC context name towards the HLR (see 
clause 3). The version indicator is described in 3GPP TS 24.010 and 3GPP TS 24.080. AC names are defined in 
3GPP TS 29.002; 

perform mapping between layer 3 messages on the radio path and TC transaction sublayer messages as required 
(see clause 3). 

2.2 MSC/VLR procedures for handling supplementary service 
signalling received over the D-interface 

Upon receipt of supplementary service signalling on the D-interface, the MSC/VLR shall: 

perform any internal SS checks or procedures appropriate to the signal (see clauses 4 and 5); 

handle any information elements according to the screening indicator procedure as described in 3GPP TS 
24.010; 

perform mapping between TC transaction sublayer messages and layer 3 messages on the radio path as required 
(see clause 3). 



SS version negotiation 



This clause describes the general procedures for the call related and call independent supplementary services version 
negotiation. 

3.1 Call related supplementary services interworking 

No interworking identified. 

3.2 Call independent supplementary services interworking 

On receipt of the REGISTER message from the MS, the MSC/VLR will include the appropriate AC name in the 
dialogue control portion of the BEGIN message based on the following rules: 

- if no version indicator is present, no AC name is included in the BEGIN message towards the HLR (no AC name 
indicates "versionl"); 

- if the version indicator is less or equal to the highest AC name the MSC/VLR and HLR both support, the 
"dialogue" will be handled according to the AC name corresponding to the version indicator and to the SS 
operation received; 
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- if the version indicator is greater than the highest commonly supported AC name within the network 

(MSC/VLR, HLR), the "dialogue" will be handled according to this highest AC name if the request from the MS 
can also be fulfilled with this version of the "dialogue". 

The selection of the highest commonly supported AC name by the network is described in 3GPP TS 29.002. 

It should be noted that unknown parameters of the extension field within the Facility Information Element shall be 
forwarded to a phase 2 HLR according to the Extensibility rules as defined in 3GPP TS 29.002. They may be discarded 
when sent to a phase 1 HLR. 

According to this version of the standards, the highest AC name is "version3". 

The description method employed in the clauses 4 to 6 is tabled showing the mapping of parameter values. The exact 
values of the parameters and parameter tags can be found in the referenced specifications. 



4 Mapping between TC transaction sublayer messages 

and layer 3 radio path messages 

This clause describes the mapping of TC transaction sublayer messages to layer 3 radio path messages over the external 
interfaces. The precise coding of these messages is given in other technical specifications. 

4.1 D-interface to A-interface mapping 

Table 4.1 shows the mapping of TC transaction sublayer messages to layer 3 messages on the radio path. 

Table 4.1 : Mapping of TC transaction sublayer messages to layer 3 radio path messages 



TC transaction sublayer message 


Layer 3 radio path message 


BEGIN 


REGISTER (note 1) 


CONTINUE (note 2) 


FACILITY/REGISTER (note 3) 


END (note 2) 


RELEASE COMPLETE/REGISTER (note 3) 


ABORT (note 2) 


RELEASE COMPLETE 


NOTE 1 : AC name is not mapped to a version indicator. 

NOTE 2: The user information field if present is discarded. 

NOTE 3: A CONTINUE or END is mapped to REGISTER if a new transaction has to be established. 



4.2 A-interface to D-interface mapping 

Table 4.2 shows the mapping of layer 3 radio path messages to TC transaction sublayer messages. 

Table 4.2: Mapping of layer 3 radio path messages to TC transaction sublayer messages 



Layer 3 radio path message 


TC transaction sublayer message 


REGISTER 


BEGIN (note) 


FACILITY 


CONTINUE 


RELEASE COMPLETE 


END 


NOTE: The right AC name shall be included, see clause 3. 
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4.3 Procedures 

The mapping from TC Transaction Sublayer messages to Layer 3 radio path messages must include a replacement of 
the tag and length of the Component Portion in the Transaction Sublayer message with the Information element 
identifier and length of the Facility Information Element for the Layer 3 message. Similarly for the reverse mapping. 
However, if a version indicator is received an AC name will be provided in the BEGIN message, see clause 3. 

All transaction sublayer messages, except the ABORT message, will normally contain one or more components. If 
components are included, the conversion algorithm described below applies. If a message does not contain a 
component, then the corresponding message is also sent without a component: messages shall not be withheld by the 
interworking function. 

For call independent SS operations each message shall only contain a single component. If a message contains more 
than one component then a RELEASE COMPLETE message with the cause "Facility rejected" (see 3GPP TS 24.008) 
and without any component shall be sent on the radio path (see 3GPP TS 24.010). 

TC Transaction sublayer messages can also contain a dialogue portion. If a user-information is received within this 
dialogue portion, it will not be conveyed in a Layer 3 radio path message. 

If an ABORT message is received in TC, a RELEASE COMPLETE message is to be sent on the radio path. The 
RELEASE COMPLETE message shall not contain any component. If a cause is to be provided to the MS, one of the 
cause codes of 3GPP TS 24.008 shall be used. 

If an ABORT message with a dialogue portion indicating "version fallback" (e.g. the cause " AC-not-supported") is 
received in TC then, if the MSC does not re-attempt the "dialogue" (e.g. by using a different AC name), it shall send a 
RELEASE COMPLETE to the MS with the cause "Facihty rejected" (see 3GPP TS 24.008) and without any 
component. 

If an END message with a dialogue portion indicating "dialogue refused" is received in TC then the MSC shall send a 
RELEASE COMPLETE to the MS with the cause "Facility rejected" (see 3GPP TS 24.008) and without any 
component. 

If a layer 3 radio path message or a component in the layer 3 radio path message is rejected by the MSC, the MSC shall: 

- return a RELEASE COMPLETE message to the MS. If the reject condition is not associated with a component, 
one of the cause codes of 3GPP TS 24.008 shall be inserted, as described below. If it is a component (except a 
REJECT component), a REJECT component with the appropriate problem code shall be inserted in the 
RELEASE COMPLETE message, as described below. If the reject condition concerns a REJECT component the 
RELEASE COMPLETE message may be empty; 

- terminate the transaction with the VLR by use of an ABORT message. 

If a dialogue cannot be established with the HLR because no common AC name is available then the MSC shall send a 
RELEASE COMPLETE to the MS with the cause "Facility rejected". 



5 Call related supplementary services management 

5.1 SS management in connection establishment phase 

When a CM connection is being set up between an MS and an MSC, setting up of a connection between the MSC and 
the VLR to request access proceeds as for normal call set-up (see 3GPP TS 29.002). Moreover, the MSC will also 
assess the capabilities of the MS according to the screening indicator (see 3GPP TS 24.010 and 3GPP TS 24.080). As 
the call set-up proceeds, the following supplementary services may apply: 

5.1 .1 Line Identification services 

These supplementary services (described in 3GPP TS 24.081) require interworking in the MSC between both 3GPP TS 
24.008, MAP (3GPP TS 29.002) and the fixed network protocol, see also 3GPP TS 29.010. 
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5.1.1.1 



Calling Line Identification Presentation (CLIP) 



The signalling at invocation of the CLIP supplementary service is shown in figure 5.1. 



MS 



MSC 

+ - + 



VLR 

+ - + 



SETUP 



SEND INFORMATION FOR INCOMING CALL SETUP 



COMPLETE CALL 



Figure 5.1 : Signalling for CLIP supplementary service 

When a call terminates at a mobile subscriber, the MSC obtains information on what supplementary services are active 
by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this 
parameter indicates that the CLIP service is provided (and CLIR is not indicated in the incoming call set-up message 
from the PSTN), then the number of the calling subscriber (if received in the incoming call set-up) shall be mapped onto 
the Calling Party BCD number parameter in the SETUP message sent to the mobile. Exact values of the parameter and 
parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.081. 



5.1.1.2 



Calling Line Identification Restriction (CLIR) 



The signalling at invocation of the CLIR supplementary service is shown in figure 5.2. 



MS 
+ - + 



MSC 

+ - + 



VLR 
+ - + 



SETUP 



SEND INFORMATION FOR OUTGOING CALL SETUP 
> 

COMPLETE CALL 



Figure 5.2: Signalling for CLIR supplementary service 

When a call originates at a mobile subscriber, the MSC obtains information on what supplementary services are active 
by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this 
parameter indicates that the CLIR service is provided and if the CLIR service shall be invoked (according to the 
presentation mode and possible subscriber request), then this information is indicated in the initial address message sent 
using the fixed network protocol (if possible). 

If this parameter indicates that the CLIR service is not provided and the calling subscriber has attempted to invoke 
CLIR, then the call set-up shall be rejected as defined in 3GPP TS 24.081. 



5.1.1.3 



Connected Line Identification Presentation (COLP) 



The signalling at invocation of the COLP supplementary service is shown in figure 5.3. 




VLR 

+ - + 



SEND INFORMATION FOR OUTGOING CALL SETUP 



COMPLETE CALL 



Figure 5.3: Signalling for COLP supplementary service 

When a call originates at a mobile subscriber, the MSC obtains information on what supplementary services are active 
by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this 
parameter indicates that the COLP service is provided, then if the connected line identity is made available by the 
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terminating network (i.e. no interworking or presentation restrictions apply) then the connected number is passed to the 
calHng mobile subscriber in the ConnectedNumber parameter in the CONNECT message. 

5.1.1.4 Connected Line Identification Restriction (COLR) 

The signalling at invocation of the COLR supplementary service is shown in figure 5.4. 



MS 

+ - + 



MSC 

+ - + 



VLR 

+ - + 



SETUP 



SEND INFORMATION FOR INCOMING CALL SETUP 
-> 

COMPLETE CALL 



Figure 5.4: Signalling for COLR supplementary service 

When a call terminates at a mobile subscriber, the MSC obtains information on what supplementary services are active 
by analysing the SS-Data parameter in the MAP_COMPLETE_CALL service primitive on the B-interface. If this 
parameter indicates that the COLR service is provided, then this information is sent to the originating network using the 
fixed network protocol (if possible). 

5.1 .2 Call Forwarding services 



5.1.2.1 



Notification to served mobile subscriber 



As described in 3GPP TS 22.082, when a subscriber has any (set of) Call Forwarding service(s) active, a notification of 
this fact is sent to the MS at mobile originated call set-up from the served mobile subscriber. The signalling for this 
notification is shown in figure 5.5. 



MS 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



SETUP 



ALERTING/ 

CONNECT/ 

FACILITY 

< 



SEND INFORMATION FOR OUTGOING CALL SETUP 
-> 

COMPLETE CALL 



Figure 5.5: Signalling for notification of invocation of Call Forwarding supplementary service 

The MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the 
MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that a call forwarding 
service is active, then any of the ALERTING, CONNECT or FACILITY messages may be used to convey the required 
NotifySS operation in a Facility information element. Exact values of the parameter and parameter tags are indicated in 
3GPP TS 24.080 and 3GPP TS 24.082. 

5.1 .3 Call Waiting service (CW) 
5.1 .3.1 Offering a waiting call 

The signalling for this situation is shown in figure 5.6. 
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MS 
+ - + 



MSC 

+ - + 



VLR 
+ - + 



SETUP 



SEND INFORMATION FOR INCOMING CALL SETUP 
-> 

PROCESS CW 



Figure 5.6: Signalling for setting up a waiting call 

A waiting call is offered to a busy MS using a normal SETUP message including a "Signal" information element with 
value #7 (call waiting tone on), as described in 3GPP TS 24.083. This is the required MSC behaviour if it has received a 
MAP_PROCESS_CALL_WAITING service primitive as a response to a 

MAP_SEND_INFO_FOR_INCOMING_CALL service primitive on the B-interface. Exact values of the parameter and 
parameter tag are indicated in 3GPP TS 24.008. 

5.1 .3.2 Notification of waiting call to calling subscriber 

The signalling for this notification is shown in figure 5.7. 



MS 

+ - + 



MSC 

+ - + 



ALERTING 



Figure 5.7: Signalling for notification of waiting call to calling subscriber 

If there are no network interworking limitations between the originating and destination MSCs, then the calling MS 
receives notification of his waiting call as follows: A Facility Information element in the ALERTING message includes 
a NotifySS operation with the following parameters: 

- SS-Code parameter indicates "callWaiting"; 

- CalllsWaitinglndicator parameter indicates "calllsWaiting". 

Exact values of the parameter and parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.083. 

5.1 .4 Closed User Group service (CUG) 
5.1 .4.1 Explicit invocation of a CUG call 

The signalling for this situation is shown in figure 5.8. 



MS 



MSC 

+ - + 



VLR 



SETUP 



I 



SEND INFORMATION FOR OUTGOING CALL SETUP 



Figure 5.8: Signalling at explicit invocation of a CUG call 

When a subscriber to the CUG supplementary service sets up a call, an explicit invocation involves transport of a 
ForwardCUG-Info operation in a Facility information element in the SETUP message. Parameter mapping between the 
air-interface SETUP message and the B-interface MAP_SEND_INFO_FOR_OUTGOING_CALL service primitive 
shall take place in the MSC. Exact values of the parameter and parameter tags are indicated in 3GPP TS 24.080 and 
3GPP TS 24.085. The parameter tags and values are mapped as follows: 

Table 5.1 : Mapping of parameter names and values for explicit invocation of a CUG call 



3GPP TS 24.080 parameter name 


3GPP TS 29.002 parameter name 
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cug-Index 


cug-Index 


suppressPrefCUG 


suppressPrefCUG 


suppressOA 


suppressOutgoingAccess 



5.1.4.2 



Notification of CUG invocation to served MS 



The signalling for this situation is shown in figure 5.9. 



MS 



MSC 

+ - + 



VLR 



CALL PROCEEDING/ 

FACILITY 
< 



SEND INFORMATION FOR INCOMING CALL SETUP 
> 

COMPLETE CALL 



Figure 5.9: Signalling flow for notification of CUG invocation to served MS 

The network may indicate to the MS that a CUG has been invoked for the outgoing call by sending a NotifySS 
operation in the Facility information element in the FACILITY or CALL PROCEEDING message towards MSa. The 
parameter to be included in this operation (cug-Index) is obtained from the MAP_COMPLETE_CALL service 
primitive. Exact values of the parameter and parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.085. 



5.1.4.3 



Notification of rejection of CUG invocation to served MS 



The signalling for this situation is shown in figure 5.10. 



MS 

+ - + 



SETUP 



MSC VLR 

+-+ +-+ 

SEND INFORMATION FOR OUTGOING CALL SETUP 



SEND INFORMATION FOR OUTGOING CALL SETUP ERROR 
< 



DISCONNECT/ 
RELEASE/ 
RELEASE COMPLETE 
< 



Figure 5.10: Signalling flow for notification of rejection of CUG invocation to served lUIS 

When an attempted CUG call is rejected for CUG related reasons, mapping of parameter values take places in order to 
inform the MSa of the failure in the DISCONNECT, RELEASE or RELEASE COMPLETE message. If the call is 
rejected by the serving VLR, a mapping of errors received on the B-interface (as response to 

MAP_SEND_INFO_FOR_OUTGOING_CALL) to diagnostics (in the diagnostics field of the Facility Rejected cause 
value) must be performed. The mapping from error code to diagnostic is as follows (detailed values of tags, cause 
values and diagnostics are found in 3GPP TS 29.002, 3GPP TS 24.008, and 3GPP TS 24.080 respectively): 

Table 5.2: IVIapping of 3GPP TS 29.002 error causes to diagnostics at notification of rejection of CUG 

invocation to served IVIS 



3GPP TS 29.002 error cause 


Facility rejected #29 diagnostic field 


outgoingCallsBarredWithinCUG 


Outgoing calls barred within the CUG 


noCUG-Selected 


No CUG selected 


unknownCUG-Index 


Unknown CUG index 


indexIncompatibleWith RequestedBasicService 


Index incompatible with requested basic service 



£75/ 



3GPP TS 29.011 version 9.0.0 Release 9 



15 



ETSI TS 129 Oil V9.0.0 (2010-01) 



If there are no network interworking restrictions (i.e. originating MSC = gateway MSC = terminating MSC), 
interworking between MAP and the air-interface takes place also for rejection of CUG calls by terminating end. The 
signalling for this situation is shown in figure 5.11. 



MSa 
+ - + 



MSC 

+ - + 



HLR 

+ - + 



SEND_ROUTING_INFO/ 
SEND_ROUTING_INFO_SMS 
(for MSb) 




DISCONNECT/ 
RELEASE/ 
RELEASE COMPLETE 

<; 



Figure 5.11 : Signalling flow for notification of rejection of CUG invocation from terminating end 

The mapping from error code to diagnostic is as follows (detailed values of tags, cause values and diagnostics are found 
in 3GPP TS 29.002, 3GPP TS 24.008, and 3GPP TS 24.080 respectively): 

Table 5.3: Mapping of 3GPP TS 29.002 error causes to cause values at notification of rejection by 

terminating end 



3GPP TS 29.002 error cause 


Cause information element (cause value) 


calledPartySSInteractionViolation 


Facility Rejected #29, 

Diagnostic = CUG call failure, 
unspecified 


incomingCallsBarredWithinCUG 


Incoming calls barred within the CUG #55 


subscriberNotMemberOfCUG 


User not a member of CUG #87 


requestedBasicServiceViolatesCUG-Constraints 


Facility Rejected #29 



5.1 .4.4 Notification of CUG invocation to terminating MS 

The signalling for this situation is shown in figure 5.12. 



MS 
+ - + 



MSC 

+ - + 



VLR 
+ - + 



SETUP 



SEND INFORMATION FOR INCOMING CALL SETUP 



COMPLETE CALL/ PROCESS CALL WAITING 



Figure 5.12: Signalling flow for notification of CUG invocation to terminating end 

When a CUG call arrives at the terminating end, the CUG index associated with the invoked CUG may be passed to the 
mobile station. The cug-Index parameter is obtained from the fixed network connection establishment request message, 
or if no fixed network protocol is involved (i.e. originating = terminating MSC), it is obtained from the 
MAP_COMPLETE_CALL or MAP_PROCESS_CALL_WAITING service primitive. Its value is mapped onto the cug- 
Index parameter in the NotifySS operation in the Facility Information element of the SETUP message on the air- 
interface. Exact values of the parameter and parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.085. 
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5.1 .5 Advice of Charge services 



5.1 .5.1 Notification of Charging information to served MS, mobile originated call 

The signalling for this situation is shown in figure 5.13. 



MSa 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



COMPLETE CALL 



CONNECT/ 
FACILITY 



Figure 5.13: Signalling flow for notification of Mobile originated Charging Information to served MS 

The network may indicate charging information to the MS at mobile originated call set-up. The MSC knows charging 
information is applicable due to the inclusion of an SS-Code indicating Advice Of Charge Charging or Advice Of 
Charge Information in the MAP_COMPLETE_CALL service indication from the VLR. This parameter's value is 
mapped onto the SS-Code parameter in the ForwardChargeAdvice operation which is to be sent to the MS together with 
the relevant charging parameters. The ForwardChargeAdvice operation shall be sent in the facility information element 
of either the CONNECT or the FACILITY message. Exact values of the parameter and parameter tags are indicated in 
3GPP TS 24.080 and 3GPP TS 24.085. 

5.1 .5.2 Notification of Charging information to served MS, mobile terminated call 

The signalling for this situation is shown in figure 5.14. 



MSb 

+ - + 



MSC 

+ - + 



VLR 
+ - + 



FACILITY 



COMPLETE CALL 



Figure 5.14: Signalling flow for notification of Mobile terminated Charging Information to served MS 

The network may indicate charging information to the MS at mobile terminated call set-up. The MSC knows charging 
information is applicable due to the inclusion of an SS-Code indicating Advice Of Charge Charging or Advice of 
Charge Information in the SS-Data parameter included in the MAP_COMPLETE_CALL service indication from the 
VLR. This parameter's value is mapped onto the SS-Code parameter in the ForwardChargeAdvice operation which is to 
be sent to the MS together with the relevant charging parameters. The ForwardChargeAdvice operation shall be sent in 
the facility information element of the FACILITY message. Exact values of the parameter and parameter tags are 
indicated in 3GPP TS 24.080 and 3GPP TS 24.085. 
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5.1 .6 Call Barring services 

These supplementary services (described in 3GPP TS 24.088) require the following interworking in the MSC: 



5.1.6.1 



Barring of outgoing calls 



The signalling for this situation is shown in figure 5.15. 



MS 
+ - + 



MSC 
+ - + 



VLR 
+ - + 



RELEASE 
COMPLETE 



SEND INFORMATION FOR OUTGOING CALL SETUP/ 
SEND INFORMATION FOR MOBILE ORIGINATED SMS 
> 

SEND INFORMATION FOR OUTGOING CALL SETUP ERROR/ 
SEND INFORMATION FOR MOBILE ORIGINATED SMS ERROR/ 

ERROR 
< 



Figure 5.15: Signalling flow for barring of an outgoing call 

If the error code "CallBarred" is received as a response to the MAP_SEND_1NF0_F0R_0UTG0ING_CALL or 
MAP_SEND_INFO_FOR_MO_SMS service primitives on the B-interface, then a RELEASE COMPLETE message 
with a NotifySS operation shall be sent to the originating MS, as described in 3GPP TS 24.088. The mapping of 3GPP 
TS 29.002 callBarringCause to 3GPP TS 24.008 cause values is shown in table 5.4. Exact values of the parameter and 
parameter tags are indicated in 3GPP TS 24.080, 3GPP TS 24.088 and 3GPP TS 24.008. 

Table 5.4: Mapping of 3GPP TS 29.002 callBarringCause to 3GPP TS 24.008 cause values at barring 

of outgoing call 



3GPP TS 29.002 callBarringCause 


3GPP TS 24.008 Cause value 


barringServiceActive 


#31: Normal Unspecified 


operatorBarring 


#8: Operator Determined Barring 


(None) 


#21: Call Rejected 



5.1 .6.2 Barring of incoming calls 

The signalling for this situation is shown in figure 5.16. 



MSa 
+ - + 



DISCONNECT/ 
RELEASE/ 
RELEASE COMPLETE 



GMSC HLRb 

+-+ +-+ 

SEND_ROUTING_INFO/ 
SEND_ROUTING_INFO_SMS 

(for MSb) 
> 

SEND_ROUTING_INFO/ 
ERROR 



Figure 5.16: Signalling flow for barring of an incoming call 

If the error code "CallBarred" is received as a response to the MAP_SEND_ROUTING_INFO or 
MAP_SEND_ROUTING_INFO_FOR_SM service primitives on the D-interface, then if no network interworking 
limitations apply, a NotifySS operation shall be sent to the originating MS in the first clearing message, as described in 
3GPP TS 24.088. The mapping of 3GPP TS 29.002 error causes to 3GPP TS 24.008 cause values is shown in table 5.5. 
Exact values of the parameter and parameter tags are indicated in 3GPP TS 24.080, 3GPP TS 24.088 and 3GPP TS 
24.008. 
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Table 5.5: Mapping of 3GPP TS 29.002 error causes to cause values at barring of incoming call 



3GPP TS 29.002 error cause 


Cause value 


barringServiceActive 


#21: Call Rejected 


operatorBarring 


#21: Call Rejected 


(None) 


#21: Call Rejected 



5.1.7 CCBS call outcome 



For the purpose of monitoring the destination B (the target of a CCBS request activated by subscriber A), the HLR on 
the B-side needs to know the outcome of a CCBS call. A CCBS call is a call being set-up after acceptation of a recall 
(indication to subscriber A that B is idle). Thus, in case of a CCBS call, on receipt of call related messages from the 
MS, the MSC shall send (via the VLR) the MAP_STATUS_REPORT to the HLR. 



MS 

+ - + 
I I 



SETUP 



MSC 
+ - + 



VLR 



HLR 

+ - + 



CONNECT/ 

ALERTING/ 

DISCONNECT/ 

RELEASE/ 

RELEASE 

COMPLETE 



CCBS CALL DELIVERY 
> 



STATUS REPORT 



Figure 5.16a: Signalling for CCBS call outcome 



The CONNECT or ALERTING messages imply that the call establishment has been successful. Then the value of the 
Outcome information element in the MAP_STATUS_REPORT is set to success. 

The DISCONNECT and RELEASE are, in this case, error messages and can contain different causes (e.g. Call Rejected 
or User Busy). The MSC translates the message and/or the cause received into the proper value for the Outcome 
information element {Failure or Busy). 

Exact coding and values of the messages and parameter tags can be found in 3GPP TS 24.008 and 3GPP TS 29.002. 

5.2 SS Management in stable connection state 

When a stable CM connection is set up between a mobile station and the network, the following supplementary services 
may apply: 

5.2.1 Call Forwarding services 



5.2.1.1 



Notification of invocation of CFB to served mobile subscriber 



As described in 3GPP TS 22.082, when the Call Forwarding on MS Busy service is invoked by the network, a 
notification of this fact may be sent to the MS. The signalling for the situation when the user is NDUB is shown in 
figure 5.17. Note that if the subscriber is not NDUB, this notification does not apply. 
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MS 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



SEND INFORMATION FOR INCOMING CALL SETUP 
-> 

COMPLETE CALL 



< 

NDUB 
established 



FACILITY 



Figure 5.17: Signalling for notification of invocation of CFB supplementary service 

The MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the 
MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that CFB is active, then the 
FACILITY message may be used to convey the required NotifySS operation in a Facility information element. Exact 
values of the parameter and parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.082. 

5.2.2 Call Hold service (HOLD) 

As described in 3GPP TS 24.083, an MS can at any time during the active phase of a call signal invocation of the Call 
Hold supplementary service towards the network. This is done by use of the HOLD message (defined in 3GPP TS 
24.080). When the MSC receives such a message, it requests access to the VLR and sends the MAP_INVOKE_SS 
service primitive to the VLR (as described in 3GPP TS 29.002). The interworking function triggers this behaviour by 
sending an internal MAP_INVOKE_SS signal to the MAP Service User of the MSC, indicating the following parameter 
values: 

- SS-Code = Call Hold; 

- BS-Code = Basic service of the on-going call. 

The signalling for this situation is shown in figure 5.18. Exact values of the parameter and parameter tags are indicated 
in 3GPP TS 24.080, 3GPP TS 24.083 and 3GPP TS 29.002. 



MS 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



HOLD 



HOLD ACK/ 
HOLD REJ 



INVOKESS 



INVOKESS ACK 



Figure 5.18: Signalling flow at invocation of Call Hold supplementary service 

If the A_INVOKE_SS signal from the MAP Service User in the MSC is empty, the HOLD ACKNOWLEDGE message 
is returned to the MS. If it refers to an error, the mapping of error causes takes place according to table 5.6. Exact values 
of the parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 29.002. 

Table 5.6: Mapping of 3GPP TS 29.002 operation errors to 3GPP TS 24.080 HOLD REJECT causes 



3GPP TS 29.002 operation error 


3GPP TS 24.080 HOLD REJECT cause 


System Failure 


#63: Service/Option not available 


DataMissing 


#100: Invalid Information Element contents 


U nexpected DataVal ue 


#100: Invalid Info, element contents 


CallBarred 


#29: Facility Rejected 


IllegalSS-Operation 


#50: Requested Facility not subscribed 


SS-ErrorStatus 


#50: Requested facility not subscribed 


SS-NotAvailable 


#69: Requested facility not implemented 
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Note that Call Retrieval requires no communication on the B-interface, and thus no interworking requirements have 
been identified. 



5.2.3 Multi Party service (MPTY) 



As described in 3GPP TS 24.084, an MS can at any time during the active phase of a call signal invocation of the Multi 
Party supplementary service towards the network. This is done by including a BuildMPTY operation (defined in 3GPP 
TS 24.080) in a FACILITY message. When the MSC receives such a request, it requests access to the VLR and sends 
the MAP_INVOKE_SS service primitive to the VLR (as described in 3GPP TS 29.002). The interworking function 
triggers this behaviour by sending an internal MAP_INVOKE_SS signal to the MAP Service User of the MSC, 
indicating the following parameter values: 

- SS-Code = MPTY; 

- BS-Code = Basic Service Code of the on-going calls. 

Note that the MSC does not allow the MPTY to be invoked if the two calls are not telephony calls. 
The signalling for this situation is shown in figure 5.19. 

VLR 

+ - + 

INVOKESS 




INVOKESS ACK 



Figure 5.1 9: Signalling flow at invocation of Multi Party supplementary service 

If the A_INVOKE_SS signal from the MAP Service User in the MSC is empty, the BuildMPTY return result is 
returned to the MS in a FACILITY message. If it refers to an error, the mapping of errors takes place according to table 
5.7. 

Table 5.7: Mapping of 3GPP TS 29.002 operation errors to 3GPP TS 24.080 BuildMPTY errors 



3GPP TS 29.002 operation error 


3GPP TS 24.080 BulldlMPTY error 


System Failure 


System Failure 


DataMissing 


SystemFailure 


UnexpectedDataValue 


System Failure 


CallBarred 


IllegalSS-Operation 


IllegalSS-Operation 


IllegalSS-Operation 


SS-ErrorStatus 


SS-ErrorStatus 


SS-NotAvailable 


SS-NotAvailable 



Note that Holding, Retrieving and Splitting a multi party requires no communication on the B-interface, and thus no 
interworking requirements have been identified. 

5.2.4 Advice of Cinarge services 

Notification of Charging information to served MS during the call 

The network may indicate revised charging parameters (as required according to 3GPP TS 22.024, 3GPP TS 22.086, 
3GPP TS 23.086 and 3GPP TS 24.086) to the MS during a call. The parameters are forwarded to MSa using the 
ForwardChargeAdvice operation in the facility information element of the FACILITY message. Exact values of the 
parameter and parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.085. 
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5.2.5 Explicit Call Transfer service (ECT) 



As described in 3GPP TS 24.091, an MS can at any time during the active phase of a call signal invocation of the 
Explicit Call Transfer supplementary service towards the network. This is done by including a ExplicitCT operation 
(defined in 3GPP TS 24.080) in a FACILITY message. When the MSC receives such a request, it requests access to the 
VLR and sends the MAP_lNVOKE_SS service primitive to the VLR (as described in 3GPP TS 29.002). The 
interworking function triggers this behaviour by sending an internal MAP_1NV0KE_SS signal to the MAP Service 
User of the MSC, indicating the following parameter values: 

- SS-Code = ect; 

- BS-Code = Basic Service Code of the on-going calls. 

Note that the MSC does not allow the ECT to be invoked if the two calls are not telephony calls. 
The signalling for this situation is shown in the following figure 5.21. 

VLR 

+ - + 

INVOKESS 




INVOKESS ACK 



Figure 5.21 : Signalling flow at invocation of Explicit Call Transfer supplementary service 

If the A_INVOKE_SS signal from the MAP Service User in the MSC is empty, the ExplicitCT return result is returned 
to the MS in a DISCONNECT/RELEASE/RELEASE COMPLETE message. If it refers to an error, the mapping of 
errors takes place according to table 5.8. 

Table 5.7: Mapping of 3GPP TS 29.002 operation errors to 3GPP TS 24.080 ExplicitCT errors 



3GPP TS 29.002 operation error 


3GPP TS 24.080 ExplicitCT error 


System Failure 


System Failure 


DataMissing 


System Failure 


UnexpectedDataValue 


System Failure 


CallBarred 


CallBarred 


IllegalSS-Operation 


IllegalSS-Operation 


SS-ErrorStatus 


SS-ErrorStatus 


SS-NotAvailable 


SS-NotAvailable 



5.3 SS Management in disconnecting phase 

When a CM connection is being released, the following supplementary services may apply: 
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5.3.1 Call Forwarding services 

Notification of invocation of CFNRy to served mobile subscriber 

As described in 3GPP TS 22.082, when the Call Forwarding on No Reply service is invoked by the network, a 
notification of this fact may be sent to the MS as the call attempt is disconnected. The signalling for this situation is 
shown in figure 5.20. 



MS 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



SEND INFORMATION FOR INCOMING CALL SETUP 
> 

COMPLETE CALL 



SETUP 
< 



: NRCT 

Timeout 
I I 

FACILITY/ 

DISCONNECT 
RELEASE/ 
RELEASE COMPLETE 
< 



Figure 5.20: Signalling for notification of invocation of CFNRy supplementary service 

The MSC obtains information on what supplementary services are active by analysing the SS-Data parameter in the 
MAP_COMPLETE_CALL service primitive on the B-interface. If this parameter indicates that CFNRy is active, then if 
required, either one of the DISCONNECT, RELEASE, RELEASE COMPLETE or FACILITY messages may be used 
to convey the required NotifySS operation in a Facility information element. Exact values of the parameter and 
parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 24.082. 



5.3.2 CCBS Request Activation 

As described in 3GPP TS 22.093, when subscriber A encounters a busy destination B, subscriber A can request the 
CCBS supplementary service (i.e. activate a CCBS request against destination B). 

The signalling for this situation is shown in figure 5.21. 



MS 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



HLR 
+ - + 



DISCONNECT 
< 

RELEASE 
-> 



RELEASE COMPLETE 
^ 



CCBS REQUEST 
> 



CCBS REQUEST ERROR 

CCBS REQUEST ACK 
^ 



REGISTER_CC ENTRY 
> 

REGISTER_CC 
ENTRY_ACK 

REGISTER_CC 

ENTRY ERROR 



Figure 5.21 : Signalling for CCBS Request Activation 
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The MS request the activation of CCBS in a Facility information element of a RELEASE message in response to a 
DISCONNECT message containing the diagnostic CCBS is possible and the Allowed Actions information element set 
to Recall is possible. Then, the MSC transmits the request in an Invoke component together with the call information 
towards the VLR in a CCBS_REQUEST message on the B-interface. The VLR forwards it in a 
MAP_REGISTER_CC_ENTRY on the D-interface. 

The outcome of the activation is sent back by the HLR in a MAP_REGISTER_CC_ENTRY_ACK or a 
MAP_REGISTER_CC_ENTRY_ERROR message. This outcome is subsequently mapped and inserted in the Facility 
information element of the RELEASE COMPLETE message from the MSC to the MS. 

Exact values of the parameters and parameter tags are indicated in 3GPP TS 24.008, 3GPP TS 24.080, 3GPP TS 24.093 
and 3GPP TS 29.002. 

5.3.3 Call Deflection service 



5.3.3.1 



Call Deflection Operation Request 



As described in 3GPP TS 24.072, a MS may signal invocation of the Call Deflection supplementary service for a 
mobile terminated call at any time after call confirmation until the call is accepted. 

The signalling for this situation is shown in figure 5.22. 



MS 

+ - + 



MSC 
+ - + 



VLR 

+ - + 



DISCONNECT 



COMPLETE CALL ERROR / PROCESS CALL WAITING ERROR 



Figure 5.22: Signalling of a Call Deflection Request 

The MS requests Invocation of Call Deflection by including a CallDeflection operation (defined in 3GPP TS 24.080) in 
a DISCONNECT message. The parameters of the CallDeflection operation of the DISCONNECT message shall be 
transferred by the MSC to the VLR with the B-interface COMPLETE_CALL_ERROR or 
PROCESS_CALL_WAITING_ERROR message. 

5.3.3.2 Call Deflection Operation Response 

Optimal Routeing of late call forwarding is not invoked 

The signalling for this situation is shown in figure 5.23. 



MS 

+ - + 



MSC 

+ - + 



VLR 

+ - + 



RELEASE 



COMPLETE CALL ERROR / PROCESS CALL WAITING ERROR 
> 

SEND INFORMATION FOR INCOMING CALL SETUP ACK / 
SEND INFORMATION FOR INCOMING CALL SETUP ERROR 



Figure 5.23: Mapping of Call Deflection Response without SOR 

The MSC shall send a CallDeflection return result to the MS if the SEND_INFO_FOR_INCOMING_CALL_ACK 
message is received from the VLR and the invocation of Optimal Routeing is not requested. The MSC shall send a 
CallDeflection return error to the MS if a SEND_INFORMATION_FOR_INCOMING_CALL_SETUP ERROR 
message is received from the VLR. The MSC shall obtain the value of the CallDeflection error from the error received 
in the SEND_INFORMATION_FOR_INCOMING_CALL_SETUP ERROR message. 
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Optimal Routeing of late call forwarding is invoked: 

The signalling for this situation is shown in figure 5.24. 



MS 
+ - + 



MSC VLR 

+-+ +-+ 

SEND INFORMATION 
FOR INCOMING CALL 

SETUP ACK 
< I 



GMSC 
+ - + 



RELEASE 



RESUME CALL HANDLING 



RESUME CALL HANDLING ACK / 
RESUME CALL HANDLING ERROR 



Figure 5.24: Mapping of Call Deflection Response in case of SOR 

If for a Call Deflection Request Optimal Routeing of late call forwarding is invoked the MSC shall send a 
CallDeflection return result to the MS if the MAP_RESUME_CALL_HANDLING_ACK is received from the GMSC. 
If a MAP_RESUME_CALL_HANDLING_ERROR message with error "ForwardingFailed" is received from the 
GMSC the MSC shall send a CallDeflection return error "ForwardingFailed" to the MS. Reception of other errors than 
"ForwardingFailed" in the MAP_RESUME_CALL_HANDLING_ERROR message shall lead to local processing in the 
MSC. 

Exact values of the parameters and parameter tags are indicated in 3GPP TS 24.080 and 3GPP TS 29.002. 



6 Call independent supplementary services 

management 

6.1 MS initiated SS Management 
6.1 .1 Connection establishment pinase 

Call independent supplementary service management takes place on a separate, dedicated CM connection between the 
mobile station and the MSC. When a request to open such a connection arrives at the MSC, the MSC will request access 
permission from the VLR, as described in 3GPP TS 29.002. It will also assess the capabilities of the MS according to 
the screening indicator, as described in 3GPP TS 24.010 and 3GPP TS 24.080. The signalling for this situation is shown 
in figure 6.1. 



MS 

+ - + 



MSC 

+ - + 



MAP User m MSC 
+ - + 



CM service request 
(CM service type = 
SS Activation) 



A_CM_SERV_REQ 
(CM service type = 
SS Activation) 



Figure 6.1 : Signalling flow for SS connection establishment 

6.1.2 Connection establisined 

At this stage of the connection, the version negotiation mechanism will be invoked as described in clause 3. The 
abstract definition of the protocol used for call independent SS operations is imported directly from 3GPP TS 29.002 
into 3GPP TS 24.080. 
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The signalling for invocation of a supplementary service operation is shown in figure 6.2, while figure 6.3 shows the 
signalling for returning the result of the supplementary service operation. Tables 6.1 and 6.2 show the mapping of 3GPP 
TS 24.080 operation codes to MAP service primitives, and vice versa respectively. The detailed mapping of the 
contents of the facility information elements to the service primitives triggering the MAP user are described in 
subclause 6.3. 



MS 

+ - + 



MSC 

+ - + 
I I 



MAP User in MSC 
+ - + 



REGISTER/FACILITY 
{SS OPERATION) 



SS SERVICE PRIMITIVE REQ 



Figure 6.2: Signalling flow for SS operation invocation 

Choice of service primitive on the basis of received facility information element is as follows: 

Table 6.1 : Mapping of 3GPP TS 24.080 operations to 3GPP TS 29.002 service primitives 



Facility information element operation 


Service primitive for MAP Service user 


RegisterSS 


A REGISTER SS 


EraseSS 


A ERASE SS 


ActivateSS 


A ACTIVATE SS 


DeactivateSS 


A DEACTIVATE SS 


InterrogateSS 


A INTERROGATE SS 


RegisterPassword 


A REGISTER PASSWORD 


ProcessUnstructuredSS-Request 


A PROCESS UNSTRUCTURED SS REQUEST 


EraseCC-Entry 


A ERASE CC ENTRY 



MS 

+ - + 



MSC 

+ - + 



MAP User in MSC 
+ - + 



REGISTER/FACILITY 
{SS OPERATION) 



SS_SERVICE PRIMITIVE CNF 
< 



Figure 6.3: Signalling flow for SS operation return result 

Choice of facility information element on the basis of received service primitive is as follows: 

Table 6.2: Mapping of 3GPP TS 29.002 service primitives to 3GPP TS 24.080 operations 



Service primitive for MAP Service user 


Facility information element operation 


A REGISTER SS 


RegisterSS 


A ERASE SS 


EraseSS 


A ACTIVATE SS 


ActivateSS 


A DEACTIVATE SS 


DeactivateSS 


A INTERROGATE SS 


InterrogateSS 


A REGISTER PASSWORD 


RegisterPassword 


A PROCESS UNSTRUCTURED SS REOUEST 


ProcessUnstructuredSS-Request 


A UNSTRUCTURED SS REOUEST 


UnstructuredSS-Request 


A UNSTRUCTURED SS NOTIFY 


ProcessUnstructuredSS-Notify 


A GET PASSWORD 


GetPassword 


A REGISTER CC ENTRY 


AccessRegisterCCEntry 


A ERASE CC ENTRY 


EraseCCEntry 



6.1.3 Connection release 

A supplementary service control connection is usually released by the network. The signalling for this situation is 
shown in figure 6.4. 
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MS 

+ - + 



MSC 
+ - + 



MAP User in MSC 
+ - + 



RELEASE COMPLETE 



A CM REL COMP 



Figure 6.4: Signalling flow for SS connection release by the network 

However, in exceptional circumstances, the MS may request release of the connection. The signalling for this situation 
is shown in figure 6.5. 



MS 

+ - + 



MSC 



+ - + 
I I 



MAP User in MSC 

+ - + 



RELEASE COMPLETE 



A CM SERV REL 



Figure 6.5: Signalling flow for SS connection release by the MS 



6.2 Network initiated SS IVIanagement 

6.2.1 Connection establishment pinase 

Call independent supplementary service management takes place on a separate, dedicated CM connection between the 
mobile station and the MSC. The MSC may need to open a connection towards the MS (as described in 3GPP TS 
24.008) to send the Network initiated SS operation to the MS. Detailed mapping rules are described in subclause 6.3. 

6.2.2 Connection establisined 

The abstract definition of the protocol used for call independent SS operations is imported directly from 3GPP TS 
29.002 into 3GPP TS 24.080. 

The signalling for invocation of a Network initiated SS operation is shown in figure 6.6, while figure 6.7 shows the 
signalling for returning the result of supplementary service operation. 

Choice of facility information element on the basis of received service primitive is described in table 6.2. 

MAP User in MSC 



MS 

+ - + 



REGISTER/FACILITY 
{SS OPERATION) 



MSC 

+-+ +-+ 

SS_SERVICE PRIMATIVE REQ ' ' 
<■ 



Figure 6.6: Signalling flow for Network Initiated SS operation invocation 

Choice of service primitive on the basis of received facility information element is described in table 6.2. 



MS 

+ - + 



MSC 

+ - + 



MAP User m MSC 

+ - + 



FACILITY 
(SS OPERATION) 



SS_SERVICE PRIMATIVE CNF 
> 



Figure 6.7: Signalling flow for Network Initiated SS operation return result 
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6.2.3 Connection release 

A Network initiated SS connection is usually released by the network. The signalling for this situation is shown in 
figure 6.4. 

However, in exceptional circumstances, the MS may request release of the connection. The signalling for this situation 
is shown in figure 6.5. 

6.2.4 ForwardCheckSSIndication 

When a mobile station first makes contact with the network after there has been a HLR restart, an indication may be 
sent by the HLR to the MS to inform of possible unintended consequences with respect to supplementary services. This 
indication is a separate service in the MAP (MAP_FORWARD_CHECK_SS_INDICATION service), and the abstract 
definition of its operation (ForwardCheckSSIndication) is imported into the 3GPP TS 24.080 protocol. 

Upon receipt of ForwardCheckSSIndication from the VLR, the MSC shall create a new call independent SS transaction 
and then send ForwardCheckSSIndication (see 3GPP TS 24.010). 

The MSC is only required to deliver ForwardCheckSSIndication if there is an active RR connection to the MS. The 
network shall not page the MS in order to deliver ForwardCheckSSIndication. 



MS 

+ - + 



MSC 

+ - + 



ForwardCheckSSInd . 
< 



VLR HLR 

+-+ +-+ 

ForwardCheckSSInd 
< 



ForwardCheckSSInd . 
< 



Figure 6.8: ForwardCheckSSIndication 



6.2.5 CCBS Recall 



As described in 3GPP TS 22.093, when destination B, target of a CCBS request activated by subscriber A, becomes 
idle, the network shall automatically recall subscriber A. When subscriber A accepts the recall, the network will 
automatically generate a CCBS call to destination B. 

The signalling for this situation is shown in figure 6.9. 



MS 
+ - + 



MSC 

+ - + 



VLR 

+ - + 



HLR 

+ - + 



CM SERVICE PROMPT 



Procedure defined 
in 3GPP TS 24 .093 



SETUP 



CCBS RUF 



I I 



CCBS RUF ACK 



REMOTE USER FREE 



I I 
I I 



REMOTE_USER FREE_ACK 
> 



I I 
I I 



Figure 6.9: Signalling for CCBS Recall 

The indication of destination B idle is sent in the MAP_REMOTE_USER_FREE service primitive. It is transmitted on 
the D-interface and relayed on the B-interface. Then, the recall procedure starts with the establishment of a CC 
connection initiated by the network with the CM SERVICE PROMPT message. The following exchange of message 
concerns only the A-interface and is not described here since it is already done in 3GPP TS 24.093. 



£75/ 



3GPP TS 29.01 1 version 9.0.0 Release 9 



28 



ETSI TS 129 011 V9.0.0 (2010-01) 



The acceptation of the recall by the user is implicit in the SETUP message sent by the MS to the MSC. This message 
contains the call information previously sent to the MS and the indication that the call in its establishment phase is a 
CCBS call. The MSC informs the HLR of this acceptation by sending a MAP_REMOTE_USER_FREE_ACK message 
on the B-interface and further on the D-interface. 

In case an error occurs (e.g. MS not reachable or Incompatible terminal), at any time of the recall procedure (i.e. just 
after the error has been received), the MSC shall send the MAP_REMOTE_USER_FREE_ERROR with the appropriate 
value for the Error information element. 

Exact values of the parameters and parameter tags are indicated in 3GPP TS 24.008, 3GPP TS 24.093 and 3GPP TS 
29.002. 



6.2.6 CCBS Monitoring 



The monitoring process is initiated by the network. It is started on the B-side as soon as subscriber B becomes a target 
of a CCBS request. It is started on the A-side when subscriber A is found to be busy or suspends a request while being 
offered a recall. Since the status of a subscriber is linked to its activity, a message sent by the MS to the MSC may lead 
to the transmission of a message containing the new status on the D-interface (i.e. the MAP_STATUS_REPORT 
service primitive). This message contains a Status information element which can take the value Idle, Not_Reachable or 
Not Idle. 

Several situations might occur, they are described in the figure 6.10. 



MS 



MSC 



VLR 

+ - + 



HLR 

+ - + 



I I 

CM SERVICE REQUEST 
> 



IMS I DETACH 
> 



RELEASE 



> 



SETUP 
> 



MS ACTIVITY 
> 



DETACH IMS I 
> 



CALL END 
> 



NOT IDLE 
> 



STATUS REPORT 
> 



STATUS REPORT 
> 



STATUS REPORT 
> 



STATUS REPORT 



Figure 6.10: Signalling for CCBS Monitoring 

For all these situations (from a to d), the transmission of the MAP_STATUS_REPORT service primitive depends on 
the possible change of status of the MS. The detailed behaviour of this procedure is described in 3GPP TS 23.093. 

Exact coding and values of the messages are indicated in 3GPP TS 24.008 and 3GPP TS 29.002. 

6.3 Mapping of Operation Codes, Error Codes, Parameter Tags 
and Parameter Contents 

6.3.1 Operation codes 

The same operation codes are used for equivalent operations in 3GPP TS 24.080 and 3GPP TS 29.002 for call 
independent supplementary service management. 
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6.3.2 Error codes 

For call independent supplementary service management, the same error codes are used for equivalent error types in 
3GPP TS 24.080 and 3GPP TS 29.002. 

The RETURN ERROR components are also constructed in the same way on both sides of the interface. 

6.3.3 Parameter tags and parameter values 

The same parameter tags and parameter values are used for equivalent parameters in 3GPP TS 24.080 and 3GPP TS 
29.002. 
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